Το σενάριο:

---

Angel
O:]

Θα μπορούσαν να παίζουν και τα δύο σαν σενάρια,

• Βελτιώσεις στην βάση πχ. Profiling, να δεις execution plans κλπ, και να καταλήξεις εάν όντως είναι optimal ή όχι. Μπορεί να καταλήξεις ότι ο SQL Server δουλεύει στο "όριο" με τα resources που έχει.
• Εάν δεν σε νοιάζει το πότε θα υπάρχει consistency μεταξύ search και "real" data, τότε η λύση με τα search tables είναι επίσης καλή. Τράπεζα εδώ στο Βέλγιο το έχει κάνει και δουλεύει μια χαρά. Και μάλιστα το πήγανε κι ένα βήμα παραπέρα κι έχουν multiple search servers με shards ανα πελάτη. Ανάλογα με το/ποιον ψάχνει, χτυπάει κι αντίστοιχο server. Βέβαια η λύση αυτή και πάλι δεν έχει νόημα εάν ο SQL Sever δουλεύει στο όριο απο άποψη resources. Ναι μεν θα είναι πιο γρήγορο, άλλα όχι ιδιαίτερα.

 

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Άγγελε καλησπέρα. Η ιδανική λύση, και δοκιμασμένη ειδικά όταν δεν έχεις χρόνο να κανείς σωστό performance running, είναι το transactional replication. Σε αυτή την περίπτωση ειδικά αν είσαι σε εσωτερικό δίκτυο 1gb το latency που θα έχεις θα είναι τις τάξεως των 10-20 ms. Για να επωφεληθείς από αυτο θα πρέπει την replica να την έχεις σε ξεχωριστή φυσική μηχανή ή αν η κυρία μηχανή σου είναι βαρβατη σε άλλο instance. Η λύση αυτη δουλεύει σε πελάτη μου εδω και 8 χρόνια και πάνω σε μια βάση πάνω απο 2ΤΒ με trillions of rows. Βέβαια πάντα υπάρχει και η δυνατότητα να βυθιστεις μέσα στην δομή της και με τα αντίστοιχα εργαλεία που έχει ο SQL να βρεις την αιτία του κακού που δεν είναι κακο να γίνει κάποια στιγμή.

---

Antonios Chatzipavlis

Εγώ πάντως πρότεινα το φθηνό σενάριο.. ακού εκεί να στήσεις ολόκληρο άλλο SQL Server.. λεφτά *δεν* υπάρχουν κύριε Χατζηπαυλή.. χεχε.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Είσαι σίγουρος ότι αυτο που προτεινες εινια φθηνό; Γιατί αν τα βάλεις κάτω δεν είναι φθηνό. Το SQL server federation με partitioned tables έχει μεγάλο κόστος σε αλλαγές που θα πρέπει να κάνει στον κώδικα ή στην βάση. Ενώ με αυτο που λέω έχει δυο connections strings ένα σε αυτη που γράφει και ένα σε αυτη που διαβάζει και αλλάζει μόνο τα σημεία που κάνει read

---

Antonios Chatzipavlis

Εσύ βλέπεις το OpEx εγώ βλέπω το CapEx.. Θεωρώ ότι σωστό Implementation είναι φθηνό. Το να ξοδέψουν κάτι χιλιάρικα για ένα Equally δυνατό μηχάνημα μόνο για το Search (με βάση αυτά που λέει ο Άγγελος, ότι το χτυπάνε τόσο συχνά και περισσότερο απο ότι τα CRUD) δεν νομίζω ότι είναι πιο φθηνό απο τις αλλαγές στον κώδικα.. Απο την άλλη αμα δεν έχουμε πλήρη εικόνα, μπορεί να λέμε και σαχλαμαρές έτσι;

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Ευχαριστώ παίδες για τις απόψεις, όπως πάντα, τίποτα δεν είναι η απόλυτη μια λύση κι απλώς ζυγίζεις ανάλογα τις περιστάσεις τις διαθέσιμες επιλογές. Κι εδώ πλέον έχουμε 2-3 και πολύ ενδιαφέρουσες :)

---

Angel
O:]

Στο χωριό μου λένε ότι το φθηνο κρέας το τρώνε οι σκύλοι. Αλλά απο οποία πλευρά και να το δεις πάλι φθηνότερη είναι η λύση που λέω, και αυτο το γράφω με τα εξής κριτήρια
1.O Άγγελος θα πρέπει να δαπανήσει χρόνο για να κάνει την έρευνα για να δει τι θέλει. Αυτο σημαίνει τουλάχιστον 20 ανθρωποημερες εργασίας άρα χονδρικα υπολόγισε 5000€ για αυτές τις ημέρες.
2. Αφού βρει το τι πρέπει να κάνει θα πρέπει να το υλοποιήσει. Αυτό χονδρικα θα θέλει άλλες 30 ημέρες μαζί με 10 ημέρες για τεστ της λύσης. Χονδρικα το κόστος για αυτές είναι 15000€.
Συνυπλογιζοντας στα παραπάνω ότι για αυτές τις ημέρες η παραγωγικότητα όσων χρησιμοποιούν την λύση θα είναι χαμηλή πράγμα που σημαίνει χάσιμο σε χρήμα που αν μπορώ σωστά να κρίνω γνωρίζοντας που είναι ο Άγγελος αυτή την στιγμή μιλάμε για ένα πόσο τουλάχιστον 50000€.
Mε αυτά τα δεδομένα ΕΣΥ τι πιστεύει τώρα; Και μην μου πεις ότι είμαι υπερβολικός και ότι εκει που είσαι τώρα δεν τα σκέφτονται έτσι γιατί σε αυτη τ.ην περίπτωση θα θεώρησω ότι και εκει απο project management και εκτίμηση κόστους είναι ελλαδισταν.

---

Antonios Chatzipavlis

anjelinio:

Ευχαριστώ παίδες για τις απόψεις, όπως πάντα, τίποτα δεν είναι η απόλυτη μια λύση κι απλώς ζυγίζεις ανάλογα τις περιστάσεις τις διαθέσιμες επιλογές. Κι εδώ πλέον έχουμε 2-3 και πολύ ενδιαφέρουσες :)

Πάνο, η αλήθεια είναι ότι ένα ακόμα SQL μηχάνημα πουλιέται πιο εύκολα σαν ιδέα σε ένα συντηρητικό περιβάλλον. Και είναι η πιο εύκολη λύση, το replication δεν τρομάζει ένα DBA. 

.. βασικά όμως με τρώει ο κ***ς μου να δοκιμάσω το service broker πρώτα.  Θέλω να μπορώ να 'push' notifications έξω.

Δεν θα κερδίσεις ιδιαίτερα με τον service broker. Αν και είμαι φανατικός οπαδός του θα την τρως και πάλι σε locks. To τηλέφωνο μου το ξέρεις πάρε με να μιλήσουμε και να σου εξηγήσω περισσότερα.

---

Antonios Chatzipavlis

Άμα αυτά είναι τα νούμερα, πάω πάσο.. Αλλά ούτε πιστεύω ότι χρειάζεται ένα ακόμα "απλό μηχάνημα" που κοστίζει λιγότερα απο το κόστος που λες, ούτε το πόσο μπορεί να κοστίζει να συντηρείτε μετά αυτό.. Και 30 μέρες για να αλλάξει τα table names στα search queries; Πολλές μου φαίνονται πάλι. Anyway, άλλο ένα πράγμα να θυμάμε για το μέλλον

Άγγελε, όντως μπορεί να έιναι πιο εύκολο να το χωνέψει, έχεις δίκιο.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.